A distributed computing environment is comprised of a group of networked computers working in concert to provide a variety of computing services. In this type of computing environment, software applications are separated into many application components. These components are distributed across the network of computers, so that different components may be executed by different computers within the distributed environment. The application components are designed to effectively operate in a distributed environment. The advantage of designing applications for a distributed computing platform include increased scalability to accommodate a large numbers of users, increased reliability, and efficient use of computing resources.
One example of a distributed computing environment is the Java™ 2platform, Enterprise Edition (J2EE) architecture, which was developed by Sun Microsystems. J2EE applications are comprised of primarily of Enterprise Java™ Beans (EJB), which are self-contained, reusable application components written in the Java™ programming language. The specification for the J2EE architecture is described in Java™ 2 Platform Enterprise Edition Specification, v1.3, available at http:/java.sun.com/j2ee/j2ee-1—3-pfd4-spec.pdf and incorporated by reference herein.
In the J2EE architecture, application components are executed within an application server program installed on each computer in a distributed computing environment. The application components for an application may be spread over many application servers within the distributed computing environment, or concentrated within a single application server located on a single computer.
The J2EE application server program provides low-level functionality needed by application components in a distributed programming environment. The functions provided by the J2EE application server program include enabling communication between the distributed application components, as well communication between different applications located within the distributed computing environment or outside this environment. The application server handles system resources, threads, memory, database connections, security, client connectivity, and transaction management. By integrating these functions into the application server, the J2EE platform allows application developers to concentrate on implementing the business logic of the application, rather than low-level functionality required by distributed applications.
As with any large-scale system, proper configuration and continuous monitoring of the distributed computing environment is essential to the system's successful operation. For example, a system administrator may need to monitor runtime statistics of the distributed computing environment in order to prevent a component of the environment from failing. Examples of such statistics include memory usage, the number of users, or the number of transactions. When one component of the distributed computing environment fails, the system administrator may need to reconfigure other portions of the distributed computing environment to compensate. At the same time, the system administrator may be able to reconfigure and repair the failed component. All of these tasks may be done with management software integrated into the distributed computing environment. In J2EE distributed computing environments, the application server may provide management resources for controlling the configuration and operation of J2EE applications and their respective components.
Despite its advantages in scalability, reliability, and efficiency, a distributed computing environment can be difficult to manage. Each of the numerous components of the distributed computing environment may need to be separately configured and monitored. With a large application, this presents thousands of different attributes that must be managed.
One way of efficiently managing a distributed computing environment is through the development of customized management software. In order to facilitate the development of management software, various standard system management protocols have been developed. These protocols allow management software to send and receive management information to any application or system component that has implemented the management protocol. Examples of management interfaces include the Simple Network Management Protocol (SNMP) and the Web-Based Enterprise Management (WBEM) standard. These management interfaces are independent of any particular type of computing platform.
Within the Java™ programming language, the Java™ Management Extensions (JMX) define a Java™-based architecture, API, and services for application and system management. JMX allows Java™ applications to become manageable without substantial modification. The specification for the Java™ Management Extensions standard is located at http://java.sun.com/aboutJava/communityprocess/final/jsr003/index.html and is incorporated herein by reference. Since JMX is integrated into the Java™ programming language, JMX can fully utilize the functionality of other existing Java™ APIs, such as Java™ Naming and Directory Interface (JNDI), Java™ Database Connectivity (JDBC), and Java™ Transaction Services (JTS). Further, JMX can be integrated with other management protocols such as SNMP and WBEM, enabling uniform management of both Java™ and non-Java™ applications.
FIG. 1 shows the basic JMX architecture implemented in the J2EE platform. Implementations in other Java™ platforms, such as Embedded Java™, follow a similar model. J2EE Application Server 100 executes J2EE components, such as EJBs. Additionally, the Application Server 100 contains Managed Beans (MBeans) 105, 110, and 115. Application Server 100 may have any number of MBeans. Each MBean represents a different manageable resource. Examples of manageable resources may include an implementation of a service, an application, or a device. Additionally, MBeans 105, 110, and 115 may represent MBeans for manageable resources associated with Application Server 100. Examples of manageable resources associated with application server 100 include network resources, such as the listen port, security settings, such as encryption levels, and run-time operations, such as server shutdowns, startups, and suspends.
MBeans are Java™ objects with attributes and methods. When an MBean's methods are invoked or an MBean's attribute are altered, the corresponding manageable resource will be affected accordingly. MBeans 105, 110, 115 are registered with MBean Server 130. MBean Server 130 is also located on Application Server 100. In an alternate embodiment, MBean Server 130 is located on a remote server. In a further variation, MBeans may be registered with multiple MBean Servers. MBean Server 130 directly controls its registered MBeans and makes them available to remote management applications. The MBean Server 130 includes a set of services for managing MBeans. These services include communication to and from each MBean, as well as services for creating and removing MBeans.
MBean Server 130 also communicates information to and from Management Applications 140, 150 and 160. Management Application 140 is a Java™ application integrated into the Application Server 100, while Management Applications 150 and 160 are remote applications. The remote Management Applications 150 and 160 may be located on a Java™ platform or an external, non-Java™ platform. Management Application 150 uses a non-JMX management protocol, such as SNMP or WBEM. MBean Server 130 translates information between the non-JMX Management Application 150 and MBeans 105,110, and 115.
Management Application 160 is a remote MBean Server. The remote MBean Server includes similar functions as MBean Server 130, including services for communicating with MBeans and Management Applications. Additionally, MBean Server 160 aggregates MBeans from Application Server 100 and Application Server 180. Information from MBean Server 160 may be passed to MBeans on Application Servers 100 and 180 directly, or through a local MBean Server. Any number of intermediate MBean Servers may exist in a distributed computing environment.
The JMX standard provides a uniform, Java™-based architecture for application and system management. In order to accommodate a wide variety of manageable resources, JMX defines a set of very generic interfaces for managing MBeans. For example, the code “void set Attribute(Object Identifier, Object attributes)” sets MBean attributes, while the code “Object get Attribute(Object Identifier, String attributeName)” would retrieve an MBean attribute.
The generic interface presented by the JMX standard is error prone on many levels. First, the correct objects and attributes used in a given method call will vary depending on the MBean called. Errors can result in several ways if the user application enters the incorrect objects or attributes when managing a MBean. If the user application misspells the name of the desired MBean or attribute, the method call will fail at runtime. Sometimes the user application will call a MBean method with a series of multiple attributes. If the attributes are miscounted or misordered, additional errors will result at runtime. Even if the user application configures the method call correctly, the user application could pass an invalid value for an attribute. For example, an attribute may have a valid numerical value between 1 and 10. A runtime error will result if the user application passes a value of 11 for this attribute.
Another problem results from using the wrong data type. Information used by MBean may be in the form of a specific data type. Examples of simple data types include strings and integers, which describe text and integer numbers, respectively. More complex data types are also used, such as ListenPort, which describes a servers network listen port setting. In the generic interface provided by the JMX standard, attributes are data typed with broad type of Object. It is up to the user application to ensure that this broad data type is handled properly. To do so, the user application must know in advance the more specific type of data used by the MBean and properly cast the specific data type. If this is done incorrectly, an error will result at runtime.
Additional problems occur due to the variety of information represented by MBeans. Many MBeans may represent manageable resources that are read-only. Examples of these attributes include server statistics, which can be read by the user application, but not written to. Other MBeans may be write-only. Examples of these manageable resources include operations for starting, stopping, and resetting application servers. Attempting to read a write-only MBean, or vice-versa, will result in an error.
Compounding this problem, many of these errors often occur only at runtime, after the application is deployed. This make debugging more time consuming, since the application must be deployed in order for the error to become apparent. Also, runtime error messages generally very vague, making it difficult to trace the source of the error.
Previously, the burden is on the user application to correctly employ MBeans with correctly named and ordered attributes, legal attribute values, and the correct data type. With the wide variety of MBeans, each with different requirements, user application mistakes are commonplace. Therefore, it is desirable to have an apparatus for employing MBeans which 1) prevents misnamed objects or attributes, 2) catches illegal attribute values, 3) avoids errors in casting data types, 4) prevents errors resulting from using the wrong function on a MBean, and 5) reduces the occurrence of difficult to trace runtime errors. Additionally, it is desirable that this apparatus is intuitive and easy to use. Further, it is desirable that this apparatus be dynamic, so that management interfaces may be extended at runtime.